Propagating fraud awareness to hosted applications

ABSTRACT

A policy enforcement point includes fraud prevention information associated with devices and/or users which is collected from: (i) many cloud fraud services located in the cloud; and/or (ii) authorization processing of users and/or devices. The policy enforcement point is consulted when a user/device undergoes authorization processing for a transaction with an application (for example, an application that serves protected content such as financial records, email, etc.). Fraud prevention information is added to session data, associated with the attempted authorization to the application, for the user/device as the user/device proceeds its attempted authorization to the application. In some cases, the authorization to the application may be refused based on the data added to the session data by the policy enforcement point or the policy enforcement point will propagate fraud prevention information to the application to make the decision.

BACKGROUND

The present invention relates generally to the field of online securityand more particularly to convergence of fraud detection and preventionservices in perimeter devices.

Fraud is a growing problem for online businesses operating, for example,in the finance industry. Conventional solutions aim to addressfinancial, and other types, of fraud by providing multiple solutionsthat operate independently of each other.

SUMMARY

According to one aspect of the present invention, a method, computerprogram product and/or system perform the following operations (notnecessarily in the following order): (i) collecting, in a fraud relateddata cache of a policy enforcement point system through a communicationnetwork and from a plurality of cloud fraud services, machine readablefraud related data; (ii) intercepting, by the policy enforcement pointsystem, a response being transmitted over a communications network froma cloud fraud service to a client device, with the response beingresponsive to a request generated by a browser script in a browser ofthe client device; (iii) determining, by the policy enforcement pointsystem, an authorization related data set, based, at least in part, onthe machine readable fraud related data, with the authorization relateddata set relating to a fraud risk of at least one of the following: theclient device, or a user of the client device; (iv) modifying, by thepolicy enforcement point system and to generate a modified response,session data included in the intercepted response to filter outsensitive data so that any sensitive data that is present in theintercepted response will not be present in the modified response; and(v) sending, by the policy enforcement point system through thecommunication network, the modified response to the client device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a block diagram of a first embodiment of a system accordingto the present invention;

FIG. 1B is a block diagram of a policy enforcement point systemaccording to the present invention, which is a sub-system of the firstembodiment system;

FIG. 2 is a flowchart showing a first embodiment method performed, atleast in part, by the first embodiment system;

FIG. 3 is a block diagram showing a machine logic (for example,software) portion of the policy enforcement point system of FIG. 1B;

FIG. 4 is block diagram of a second embodiment of a system according tothe present invention; and

FIG. 5 is a flowchart of a second embodiment of a method performed bythe second embodiment system.

DETAILED DESCRIPTION

In some embodiments of the present invention, a policy enforcement pointincludes fraud prevention information associated with devices and/orusers which is collected from: (i) many cloud fraud services located inthe cloud; and/or (ii) authorization processing of users and/or devices.The policy enforcement point is consulted when a user/device undergoesauthorization processing with respect to an application (for example, anapplication that serves protected content such as financial records,email, etc.). In some embodiments, fraud prevention information is addedto session data, associated with the attempted authorization to theapplication, for the user/device as the user/device proceeds itsattempted authorization to the application. In some embodiments, thepolicy enforcement point may: (i) poll the cloud fraud services tomaintain currency for fraud session data; and/or (ii) propagate newfraud prevention information to the many cloud fraud services present inthe cloud. Some embodiments of the present disclosure include one, ormore, of the following features, characteristics and/or advantages: (i)a user session with fraud analysis results of a device so thatauthorization policies may be applied at a gateway independent of anapplication tier and independent of the device; (ii) determination, on acase by case basis, the trustworthiness of a device being presented;(iii) extension of conventional user-based authorization solutions toinclude detection of fraud within the context of a user's requestedoperation; (iv) convergence, at a gateway, of the presence of malware ona device with user authorization and victim identification, to provide asingle enforcement point for making access control decisions; and/or (v)a trusted channel to deliver device fraud metadata and user relatedfraud metadata to the application.

This Detailed Description section is divided into the followingsub-sections: (i) The Hardware and Software Environment; (ii) ExampleEmbodiment; (iii) Further Comments and/or Embodiments; and (iv)Definitions.

I. The Hardware and Software Environment

The present invention may be a system, a method, and/or a computerprogram product. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Smalltalk, C++ or the like, andconventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

An embodiment of a possible hardware and software environment forsoftware and/or methods according to the present invention will now bedescribed in detail with reference to the Figures. FIGS. 1A and 1Bcollectively make up a functional block diagram illustrating variousportions of networked computers system 100, including: policyenforcement point sub-system (PEP s/s or PEP) 102; client devices 104 a,b, communication network 114; cloud fraud services 120 a, b, c;protected content 124 a, b; application servers 126 a, b; cloud 128;client browsers 150 a, b; client browser code (also herein sometimesreferred to as “browser script”) 152 a, b; PEP computer 200;communication unit 202; processor set 204; input/output (I/O) interfaceset 206; memory device 208; persistent storage device 210; displaydevice 212; external device set 214; random access memory (RAM) devices230; cache memory device 232; and program 300.

Sub-system 102 is, in many respects, representative of the variouscomputer sub-system(s) in the present invention. Accordingly, severalportions of sub-system 102 will now be discussed in the followingparagraphs.

Sub-system 102 may be a laptop computer, tablet computer, netbookcomputer, personal computer (PC), a desktop computer, a personal digitalassistant (PDA), a smart phone, or any programmable electronic devicecapable of communicating with the client sub-systems via network 114.Program 300 is a collection of machine readable instructions and/or datathat is used to create, manage and control certain software functionsthat will be discussed in detail, below, in the Example Embodimentsub-section of this Detailed Description section.

Sub-system 102 is capable of communicating with other computersub-systems via network 114. Network 114 can be, for example, a localarea network (LAN), a wide area network (WAN) such as the Internet, or acombination of the two, and can include wired, wireless, or fiber opticconnections. In general, network 114 can be any combination ofconnections and protocols that will support communications betweenserver and client sub-systems.

Sub-system 102 is shown as a block diagram with many double arrows.These double arrows (no separate reference numerals) represent acommunications fabric, which provides communications between variouscomponents of sub-system 102. This communications fabric can beimplemented with any architecture designed for passing data and/orcontrol information between processors (such as microprocessors,communications and network processors, etc.), system memory, peripheraldevices, and any other hardware components within a system. For example,the communications fabric can be implemented, at least in part, with oneor more buses.

Memory 208 and persistent storage 210 are computer-readable storagemedia. In general, memory 208 can include any suitable volatile ornon-volatile computer-readable storage media. It is further noted that,now and/or in the near future: (i) external device(s) 214 may be able tosupply, some or all, memory for sub-system 102; and/or (ii) devicesexternal to sub-system 102 may be able to provide memory for sub-system102.

Program 300 is stored in persistent storage 210 for access and/orexecution by one or more of the respective computer processors 204,usually through one or more memories of memory 208. Persistent storage210: (i) is at least more persistent than a signal in transit; (ii)stores the program (including its soft logic and/or data), on a tangiblemedium (such as magnetic or optical domains); and (iii) is substantiallyless persistent than permanent storage. Alternatively, data storage maybe more persistent and/or permanent than the type of storage provided bypersistent storage 210.

Program 300 may include both machine readable and performableinstructions and/or substantive data (that is, the type of data storedin a database). In this particular embodiment, persistent storage 210includes a magnetic hard disk drive. To name some possible variations,persistent storage 210 may include a solid state hard drive, asemiconductor storage device, read-only memory (ROM), erasableprogrammable read-only memory (EPROM), flash memory, or any othercomputer-readable storage media that is capable of storing programinstructions or digital information.

The media used by persistent storage 210 may also be removable. Forexample, a removable hard drive may be used for persistent storage 210.Other examples include optical and magnetic disks, thumb drives, andsmart cards that are inserted into a drive for transfer onto anothercomputer-readable storage medium that is also part of persistent storage210.

Communications unit 202, in these examples, provides for communicationswith other data processing systems or devices external to sub-system102. In these examples, communications unit 202 includes one or morenetwork interface cards. Communications unit 202 may providecommunications through the use of either or both physical and wirelesscommunications links. Any software modules discussed herein may bedownloaded to a persistent storage device (such as persistent storagedevice 210) through a communications unit (such as communications unit202).

I/O interface set 206 allows for input and output of data with otherdevices that may be connected locally in data communication with servercomputer 200. For example, I/O interface set 206 provides a connectionto external device set 214. External device set 214 will typicallyinclude devices such as a keyboard, keypad, a touch screen, and/or someother suitable input device. External device set 214 can also includeportable computer-readable storage media such as, for example, thumbdrives, portable optical or magnetic disks, and memory cards. Softwareand data used to practice embodiments of the present invention, forexample, program 300, can be stored on such portable computer-readablestorage media. In these embodiments the relevant software may (or maynot) be loaded, in whole or in part, onto persistent storage device 210via I/O interface set 206. I/O interface set 206 also connects in datacommunication with display device 212.

Display device 212 provides a mechanism to display data to a user andmay be, for example, a computer monitor or a smart phone display screen.

The programs described herein are identified based upon the applicationfor which they are implemented in a specific embodiment of theinvention. However, it should be appreciated that any particular programnomenclature herein is used merely for convenience, and thus theinvention should not be limited to use solely in any specificapplication identified and/or implied by such nomenclature.

The descriptions of the various embodiments of the present inventionhave been presented for purposes of illustration, but are not intendedto be exhaustive or limited to the embodiments disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art without departing from the scope and spirit of the describedembodiments. The terminology used herein was chosen to best explain theprinciples of the embodiments, the practical application or technicalimprovement over technologies found in the marketplace, or to enableothers of ordinary skill in the art to understand the embodimentsdisclosed herein.

II. Example Embodiment

FIG. 2 shows flowchart 250 depicting a method according to the presentinvention. FIG. 3 shows program 300 for performing at least some of themethod operations of flowchart 250. This method and associated softwarewill now be discussed, over the course of the following paragraphs, withextensive reference to FIG. 2 (for the method operation blocks) and FIG.3 (for the software blocks).

Processing begins at operation S255, where relay module (“mod”) 302 ofprogram 300 of PEP s/s 102 relays a request: (i) from client browser 150a of client device 104 a; (ii) made through network 114; and (iii) tocloud fraud service 120 b. (See FIG. 1A.) In this example, clientbrowser 150 a has made this request in parallel to an attemptedauthorization to application server 126 b so that client device 104 acan access protected content 124 b. (See FIG. 1A.) Alternatively, thisrelayed request may come from application server 126 b. As a furtheralternative, in some methods according to the present disclosure, PEPs/s 102 does not relay this request, but, instead, the request proceedsdirectly from client device 104 a and/or application server 126 b tocloud fraud service 120 b in cloud 128 (see FIG. 1A).

With respect to the mechanism by which browser 150 a of client device104 a is caused to send the request, in this embodiment, browser script152 a executes within browser 150 a to detect a potential fraudulentactivity occurring in real time. In response, browser script 152 a isprogrammed to send out the request. Conventionally, these types ofrequests are sent directly to a cloud fraud service in the clouddesignated by the browser script. In this example, browser script 152 ahas been modified so that the request is sent first to PEP 102, whichthen relays the request to CFS 120 b at operation S255.

Processing proceeds to operation S260, where process response mod 304 ofPEP 102 intercepts the response to the client response that is sent backfrom cloud fraud service (CFS) 120 b and intended for client device 104a. More specifically, CFS 120 b is the CFS typically used by applicationserver 126 b in evaluating user/device requests for access. CFS 120 bincludes some conventional fraud protection information (also sometimesherein referred to as “fraud related data”), and, in conventionalsystems, application server 126 b would be limited to this portion offraud related data in evaluating requests for access to protectedcontent from various users/devices. However, as will be discussed inconnection with subsequent operations of method 250, in this embodiment,PEP 102 applies greatly expanded and augmented fraud protectioninformation in evaluating a user/device seeking authorization through arequest and response thereto.

Processing proceeds to operation S265, where authorization determinationsub-module (“s/m”) 320 of program 300 determines an “authorizationrelated data set.” As used herein, an authorization related data set isa set of machine readable data that includes fraud related informationrelevant to the request sent by the client's browser code. In someembodiments, the information of the authorization related data set canallow a targeted device (such as app server 126 b) to prevent, or stop,in real time, fraudulent transactions being made in the currentcommunication session by client device 104 a and its user. The fraudrelated information of the authorization related data set is selectivelychosen by authorization determination sub-module 320 of process responsemodule 304 of program 300 from fraud related data cache 324 of processresponse module 304. In this embodiment, fraud related information ismaintained on a client-by-client basis (see client record 350 in FIG.3).

In this embodiment, fraud related data cache 324 of PEP 102 is updatedfrequently to maintain current and comprehensive from information drawn,in part, from many sources (for example, CFS's 120 a, b, c).Alternatively, in some embodiments, the fraud related data cache queriesvarious machines that are connected in data communication with PEP 102in order to obtain the fraud related information needed forauthorization related data set. In this kind of embodiment, PEP 102might, for example, responsive to intercepting a response: (i) sendqueries to CFS 120 a, 120 b and 120 c requesting fraud related dataabout client device 104 a; and (ii) store the query responses in memory(for example, a fraud related data cache) while the authorizationrelated data set is determined by the authorization determinationsub-module.

The content of fraud related information included in a givenauthorization related dataset will vary depending upon system design andcontextual factors. For example, in some embodiments, the authorizationrelated data set may be as simple as a recommendation of whether clientdevice 104 a should be allowed (for example, by app server 126 b) tocontinue in its current communication session. In other embodiments, theinformation of the authorization related data set will be dominated byfactual information about various users and various devices, but willnot include any sort of recommendation for any sort of specific action.

In some embodiments, the authorization related data set may include aset of updates that PEP 102 has made to its local data store, namelyfraud related data cache 324. This may be helpful to other servicestrying to maintain their own fraud related data stores current with thatof PEP 102.

As shown in FIG. 3, fraud related data cache 324 includes a clientrecord 350 that has data that: (i) corresponds to the user of clientdevice 104 a; and (ii) has been collected from previous attempts by thisclient to authorize transactions with various applications (for example,application server 126 a) using various cloud fraud services (forexample, CFS 120 a, 120 b, 120 c). In this way, fraud related data cache324 of program 300 of PEP 102 will tend to have more comprehensive fraudrelated data about the users/devices than would a single conventionalCFS such as CFS 120 b (that is, the particular, single CFS that wasbeing consulted in this example).

In this example, client record 350 includes: (i) identificationinformation 352 that is related to the user (or purported user) ofclient device 104 a; (ii) actions information 354 that is related tocommunication network actions taken by client device 104 a and/or by itsuser; and (iii) device information 356 relating to various devices thatthe user has used during previous authorization attempts to variousapplication servers. In this example: (i) identification information 352of client record 350 of fraud related data cache 324 indicates that a“man in the browser event” is occurring (a “man in the browser event” isa condition that is conventionally understood to be associated withfraudulent transactions associated with browser manipulation); (ii)actions information 354 indicates that device 104 a and its userhabitually makes financially-related communications, in an unencryptedmanner, over publicly-accessible WiFi networks; and (iii) deviceinformation 356 indicates that the user also uses another device (hereincalled “User's Home Computer”) and that User's Home Computer was used, ayear ago, in a fraudulent financial transaction. In this example,because of all the negative indications noted in this paragraph, themachine logic rules of authorization determination s/m 320 determinethat device 104 a will undergo authorization processing with respect toa transaction involving application server 126 b.

Before moving from operation S265 to S270, it will be noted that theremay be variation in the order of operations. For example, operation S265could be performed later in method 250.

Processing proceed to operation S270 where modify response s/m 322 ofprocess response mod 304 of program 300 of PEP 102 modifies theresponse, intercepted at operation S260 from CFS 120 b, to filter fraudrelated authorization data from the intercepted response to obtain amodified response. The filtered fraud related authorization data: (i) ismerged into the PEP's session cache; and (ii) may make up all, or atleast a part of, the “authorization related data set” (see operationS265, discussed above). This fraud related authorization data is thenfiltered out of the response with a processing success being returned tothe client. When the client device later issues a request to theapplication server, this cached fraud related authorization data is usedto perform an authorization decision (along with user/group data) by thePEP, and this might indicate permit/deny/flag/etc., before the requestis passed to the application server (optionally) including the fraudrelated authorization data. The application server would then use thisinformation to enrich its authorization processing to include fraud aswell as traditional transactional information.

In this embodiment, the modified response (to be sent to the clientdevice) indicates that authorization was “successful” (the form andformat of the information indicating “success” varies with context,system software, system hardware, etc.). This response is generated as aresult of authorization processing that considers the session data. Thekey here is that the session data is updated to indicate the status ofthe fraud current user/device. Data returned by the cloud may bepersisted in the session data. The response to the client (sometimesherein referred to as a “modified response”) is designed to avoidrevealing to the fraud perpetrator (that is, the user of client device104 a) that the response to the request initiated by browser script 152a of client device 104 a has resulted in anything other than success.For example, a “generic response” indicating success may be provided inthe session data of the modified response that is sent back to clientdevice 104 a.

However, upon functional requests to the application server, the fraudrelated data of the authorization related data set (generated atoperation S265) will be used, by PEP 102 and/or app server 126 b, todetermine authorization (for example, authorization to access protectedcontent 124 b). Optionally, these functional requests to the applicationserver will be modified to include the session data so that theapplication server itself has additional information to make anindependent decision. Note that there will be cases where authorizationis not applied at the policy enforcement point, but rather delegated tothe application server. In most cases, it is expected that theapplication server will have greater transactional context to make sucha decision, with the support of the propagated session data. Theenforcement can therefore be done by the PEP or the application server.

Processing proceeds to operation S285, where send modified response mod306 of program 300 of PEP 102 sends the response, with its modifiedsession data (modified at operation S270, discussed above), to browser150 a of client device 104 a so that authorization will not go forwardand appropriate messages can be displayed on the user interface ofclient device 104 a. In this embodiment, the response from the cloudservice (via PEP 102) will be only back to a client. The applicationserver is downstream from the PEP, which is always inline. In thisembodiment, the fraud detection response data traverses through the PEPback to the client device, and the modified response (where the frauddata is extracted) never goes to the application server. However, fraudis effectively prevented because when the client device issues arequest, the PEP will use session data to authorize the request, and(when appropriate) insert fraud related data into the request to theapplication server.

Processing proceeds to operation S294, where the authorization relateddata set is sent to app server 126 b. In this embodiment, app server 126b includes machine logic (not separately shown) that receives andanalyzes the fraud related data in the authorization related data set todetermine whether, and under what conditions, its communication sessionwith client device 104 a should continue. As mentioned above, theauthorization related data set may additionally be sent to othersystems, such as CFS's 120 a, b, c.

III. Further Comments and/or Embodiments

Some embodiments of the present invention recognize the following facts,potential problems and/or potential areas for improvement with respectto the current state of the art: (i) in some conventional on-premisesdeployments, integration effort is required in order to connect existingenforcement points to fraud detection solutions; (ii) these solutionsprovide multiple independent (siloed) integration points to applyfinancial fraud intelligence to transactions, covering devicetrustworthiness and user account takeover; (iii) some of theseapproaches fail to make use of optimization that, when thesecapabilities are combined, can provide a more powerful fraud preventionsolution at the enforcement point; and/or (iv) some conventional methodscreate a unique device identifier, save the identifier on the device anduse the identifier in conjunction with a user access engine to influencehow data is presented to the user (by way of authorization) or if atransaction should proceed, but in an internet context, this method isflawed; and/or (v) access control decision are done across differentlayers in a system, for example, at a gateway (for device specificinformation) and at an application (for user fraud information).

Some embodiments of the present invention may include one, or more, ofthe following features, characteristics and/or advantages: (i) avoidsadditional integration complexity and cost associated with solutionsthat require multiple enforcement points; (ii) avoids decreasedperformance associated with integration of a fraud solution at multiplelocations; (iii) provides a single trusted point for gathering frauddata and propagating the fraud data to downstream applications; (iv)provides a single, trusted point for preventing fraud at downstreamapplications; (v) provides a broader solution that allows a singleenforcement point to participate as an all-encompassing fraud bordergateway; and (vi) eliminates inefficiencies present in the siloedsolutions described in the above paragraph.

Some embodiments of the present invention may include one, or more, ofthe following features, characteristics and/or advantages: (i) enhancingcloud fraud services to provide fraud data securely to authenticatedpolicy enforcement points; (ii) allowing enforcement points to query andsubsequently associate (converge) fraud data with user and devicecontext information; (iii) using this converged information to enhancegateway user/device authorization decision processing; and (iv) allowingpropagation of this information so consistent policy can be appliedacross application tiers.

Some embodiments of the present invention may include one, or more, ofthe following features, characteristics and/or advantages: (i)simplifies deployment by removing multiple configuration requirementsfor an end to end use case; (ii) provides enhanced authorizationcapabilities enabled by convergence of fraud data at the gateway; (iii)ensures consistency of fraud data across an end to end deploymentscenario; and/or (iv) improves performance by removing multipleapplication programming interface (API) calls to a fraud service.

Some embodiments of the present invention include: (i) a client device(a mobile device or web browser used by a user to access protectedcontent); (ii) a policy enforcement point (such as a reverse proxy);(iii) a cloud fraud detection system (a system used to determine userand device fraud risk and threat); and/or (iv) a protected resource(content of value securely exposed by web or APIs).

As shown in block diagram 400 of FIG. 4, some embodiments of the presentinvention include: client device 410; gateway enforcement point 404;cloud fraud detection system 406; resource server 412; protectedresource 408; downstream application 409; and trusted communication path414.

In some embodiments of the present invention, client device 410 executesbrowser code that results in a request to the cloud fraud service, viathe policy enforcement points. In response, gateway enforcement point404 queries cloud fraud detection system 406 for fraud data related tothe client device and/or the user thereof (user not separately shown inthe figures). The fraud data is associated with the user/device sessionand cached at the enforcement point for propagation to downstream policyenforcement points (not separately shown in the figures) forauthorization.

A method, shown in interaction block diagram 500 of FIG. 5, will now bediscussed. Processing begins at interaction S501 where client device 410requests access to protected resource 408 and connects to gatewayenforcement point 404. The client device establishes an authenticatedsession with the enforcement point. Client device executes browser codethat results in a request to the cloud fraud service, via the policyenforcement points. The gateway enforcement point forwards the requestto the resource server 412, optionally including the fraud session datacached as part of the S503/S504 interactions.

Processing begins at interaction S503 where the fraud detection payload,executed in the client device, initiates interactions with cloud frauddetection system 406, through gateway enforcement point 404.

Processing continues at interaction S504 where gateway enforcement point404 sends a request to cloud fraud detection system 406, based on thesession established with the client device. The enforcement pointprovides a session identifier, so that in-session fraud informationupdates can be gathered from cloud fraud detection system 406. The cloudfraud detection system recognizes that the request is received from atrusted gateway device (gateway enforcement point 404), and insertsadditional fraud data about the user (not shown in the Figures) andclient device 410 to be cached at the gateway enforcement point 404.Interactions S503 and S504 are performed in a loop, that is, once foreach cloud fraud detection system (such as system 406) that has updatescollected from it.

Gateway enforcement point 404 then takes the payload and augmentstraditional user based session data with fraud data. Gateway enforcementpoint 404 filters the fraud related session data from the S503 responseand returns a generic successful response to the client.

Some embodiments of the present invention now continue the processingbeginning with interaction S505 where cloud fraud detection systemreturns fraud data to be cached and associated with the user's sessionat gateway enforcement point 404. Cloud fraud detection system 406 linksthe user's session to the fraud detection results for polling ininteraction S504.

Processing continues with interaction S506 where gateway enforcementpoint 404 uses the session identifier (optionally) to poll cloud frauddetection system 406 for updated fraud information throughout theduration of a user session. Interaction S506 is performed using a nestedloop: (i) an outer loop that repeats at time intervals; and (ii) aninner loop that polls the various cloud fraud detection systems (system406 and other systems not shown in FIG. 5). The fraud data is alsoalways returned from the cloud to the gateway enforcement point, and isnever returned to the client. The PEP only downstreams fraud data to theapplication so that it (optionally) can take action. The source of frauddata is from the Client to the CFS (through the gateway enforcementpoint) of from the CFS to the PEP (per the looping S506 mechanism).

Processing continues with interaction S507 where gateway enforcementpoint 404 makes context authorization decisions using fraud information.Alternatively, a policy decision point (not shown in the Figures) makesthese context decisions on behalf of the enforcement point.

Processing continues with interaction S508 where context decisionsdetermine the next appropriate action. Example context decisionsinclude: (i) permit access; (ii) notify resource owner of at-risk users;and/or (iii) perform auditing (logging of accesses to a protected systemand protected resources) and remediation. In the case that the requestfrom S501 is permitted, the request is passed to the application server,optionally including the cached fraud data.

Processing continues at interaction S502 where resource server 412returns protected resource 408 (the requested payload).

Some embodiments of the present invention may include one, or more, ofthe following features, characteristics and/or advantages: (i) takesadvantage of the trusted path aspect of a network device (for example, asecurity access manager appliance) to a public cloud fraud service, byproviding fraud related intelligence data on this trusted path, whichcan be used in downstream applications to enforce a security policy;(ii) enhances the value of a conventional security solution; and/or(iii) consolidates multiple integration points of a conventional cloudfraud service into a consolidated gateway authorization solution.

Some embodiments of the present invention consolidate fraud and useraccess management to give security policy teams the ability to convergeinto a single security policy at a gateway device. It does this by usingan association of user session data with characteristics (for example, amalware infection) of the associated client device so that a converged(that is, a consistent) security policy can be applied throughout adeployed web (or cloud based) solution.

Some embodiments of the present invention focus on convergence of useraccess management and fraud detection, but providing a converged view ofa client connected device and user for authorization purposes.Embodiments of the present invention focus on an ability to convergefraud (on the endpoint), and user data, to make better informedauthorization decisions for current web based access.

Some embodiments of the present invention converge disparate enforcementpoints across an n-tier architecture. With the emergence of “cloud frauddata,” the convergence results in a solution where an on-premise devicecan consolidate fraud data so that it can be easily converged with otherauthorization services (such as user access management). Someembodiments of the present invention further eliminate the need forexpensive programmatic integration, thus being a lower cost alternativeto conventional deployment models.

Some embodiments of the present invention embody: (i) a specific fraudsolution that allows a trusted border gateway device to store devicespecific malware detection data (retrieved from a fraud cloud service)within the gateway device; (ii) providing this data back to such agateway service; (iii) making user access and device fraud decisionseasier, as the information is bound together at the gateway; and/or (iv)provision of a mechanism for binding the information together at thegateway.

Some embodiments of the present invention propagate user and devicefraud data to hosted applications by: (i) enhancing cloud fraud servicesto provide fraud data securely to authenticated policy enforcementpoints; (ii) allowing enforcement points to query and subsequentlyassociate fraud data with user and device context information; (iii)using this converged information to enhance gateway user/deviceauthorization decision processing; and/or (iv) allowing propagation ofthis information such that consistent policy can be applied acrossapplication tiers.

In some embodiments of the present invention, the channel availablebetween a gateway and a service is trusted, enabling the solution toconsume, filter, and cache for propagation, a broad set of data about auser and the user's devices.

The following example use case illustrates operation of one embodimentof the present invention: (i) a user logs in to a service using deviceA, where device A is determined to bear some fraudware, or has beeninvolved in actions having security implications; (ii); the system linksthe user's identity with the fraudware and/or past actions that have hadsecurity implications; and (iii) the service takes appropriate securityaction(s) based on relevant information available concerning the user,devices A and B, and/or past user actions having had securityimplications. Action taken at this point should not allow an attacker onthe client device to detect a change in behavior. Hence, an example ofan appropriate response would be to allow a user to login, but to reducethe set of permissible actions taken for the session. This might eveninclude delaying transaction processing while informing the device ofsuccess.

Further to the example illustrated above: (i) the gateway understandsthe state of device B; and (ii) subsequently issues an application APIcall that queries the user's historical compromised state (for example,compromised because of device A). Hence, the decision to block loggingin is made at the application, subsequent to the current device check.

Some embodiments of the present invention may include one, or more, ofthe following features, characteristics and/or advantages: (i) thegateway becomes a trusted client to the service; (ii) the gatewayaccommodates (collects and makes use of) service fraud data thatotherwise would not be available.

Some embodiments of the present invention, converge client fraud data(from the service) with fraud data associated with the user (from thegateway) into a set of claims that can more accurately determineuser/device authorization (in a gateway). Further, with the gatewayintegrated with the service, the trusted (inline) channel is used topropagate data back to the gateway so that the data can be used fordownstream applications.

Some embodiments of the present invention may include one, or more, ofthe following features, characteristics and/or advantages: (i) convergesa user's session with fraud analysis (for example, financial fraud)results of a device (performed as part of a “service”) so thatauthorization policies may be applied at a gateway independent of anapplication tier and independent of the device (fraud in this context isinternet-originated fraud that may only be detected as part of a globalintelligence effort, and hence the fraud decision engine resides in a“cloud”); (ii) relies on the cloud to determine, on a case by casebasis, the trustworthiness of a device being presented; (iii) extendsconventional user-based authorization solutions to include detection offraud within the context of a user's requested operation; (iv) convergesdevice malware presence with user authorization and victimidentification (to help detect whether the user been subjected to asuccessful attack in the past) at a gateway, to provide a single“choke-point” for making access control decisions; and/or (v)convergence of device specific information and user specific informationat a gateway provides a trusted channel to downstream device fraudmetadata and user related fraud metadata to the application.

Some embodiments of the present invention may include one, or more, ofthe following features, characteristics and/or advantages: (i) enhancescloud fraud services to provide fraud data securely to authenticatedpolicy enforcement points (PEP); (ii) allows enforcement points to queryand subsequently associate fraud data with user and device contextinformation; (iii) uses this converged information to enhance gatewayuser/device authorization decision processing; (iv) allows propagationof this information so that consistent policy can be applied acrossapplication tiers; (v) by implementation of this convergence, thetrusted response channel created between the PEP and the cloud is usedto exchange additional information that can be associated with thecurrent user/device session; (vi) once this information is in the activesession (in the PEP), propagates the information to application serversthat are hosted in-line with the PEP; and/or (vii) greatly simplifies anintegrated solution where user access and fraud detection areimplemented.

IV. Definitions

Present invention: should not be taken as an absolute indication thatthe subject matter described by the term “present invention” is coveredby either the claims as they are filed, or by the claims that mayeventually issue after patent prosecution; while the term “presentinvention” is used to help the reader to get a general feel for whichdisclosures herein are believed to potentially be new, thisunderstanding, as indicated by use of the term “present invention,” istentative and provisional and subject to change over the course ofpatent prosecution as relevant information is developed and as theclaims are potentially amended.

Embodiment: see definition of “present invention” above—similar cautionsapply to the term “embodiment.”

and/or: inclusive or; for example, A, B “and/or” C means that at leastone of A or B or C is true and applicable.

Including/include/includes: unless otherwise explicitly noted, means“including but not necessarily limited to.”

User/subscriber: includes, but is not necessarily limited to, thefollowing: (i) a single individual human; (ii) an artificialintelligence entity with sufficient intelligence to act as a user orsubscriber; and/or (iii) a group of related users or subscribers.

Module/Sub-Module: any set of hardware, firmware and/or software thatoperatively works to do some kind of function, without regard to whetherthe module is: (i) in a single local proximity; (ii) distributed over awide area; (iii) in a single proximity within a larger piece of softwarecode; (iv) located within a single piece of software code; (v) locatedin a single storage device, memory or medium; (vi) mechanicallyconnected; (vii) electrically connected; and/or (viii) connected in datacommunication.

Computer: any device with significant data processing and/or machinereadable instruction reading capabilities including, but not limited to:desktop computers, mainframe computers, laptop computers,field-programmable gate array (FPGA) based devices, smart phones,personal digital assistants (PDAs), body-mounted or inserted computers,embedded device style computers, application-specific integrated circuit(ASIC) based devices.

Browser script: any code in a browser that effects a request for browserinterrogation, regardless of whether the code was added to apre-existing browser, or, written into the browser when the browser wasoriginally written, or added to the response by a website, and alsoregardless to whether the browser script appears in contiguous fashionin the larger code of the browser.

Authorization processing: any processing used to determine whether aclient device is authorized to engage in a transaction performed througha communication network; in some embodiments, the result of a successfulauthorization decision may be to allow, flag or deny; in the case offlag operation, a fraudulent transaction may have been detected, andhalted, but the response to the client device indicates successfulcompletion.

What is claimed is:
 1. A computer implemented method comprising:collecting, in a fraud related data cache of a policy enforcement pointsystem through a communication network and from a plurality of cloudfraud services, machine readable fraud related data; intercepting, bythe policy enforcement point system, a response being transmitted over acommunications network from a cloud fraud service to a client device,with the response being responsive to a request generated by a browserscript in a browser of the client device; determining, by the policyenforcement point system, an authorization related data set, based, atleast in part, on the machine readable fraud related data, with theauthorization related data set relating to a fraud risk of at least oneof the following: the client device, or a user of the client device;modifying, by the policy enforcement point system and to generate amodified response, session data included in the intercepted response tofilter out sensitive data so that any sensitive data that is present inthe intercepted response will not be present in the modified response;and sending, by the policy enforcement point system through thecommunication network, the modified response to the client device. 2.The computer implemented method of claim 1 further comprising: sending,by the policy enforcement point system to an application server involvedin a communication session with the client device, the authorizationrelated data set.
 3. The computer implemented method of claim 1 furthercomprising: propagating, by the policy enforcement point system, theauthorization related data set to the plurality of cloud services. 4.The computer implemented method of claim 1 wherein the authorizationrelated data set indicates fraud having been conducted against the useror underway on the client device.
 5. The computer implemented method ofclaim 1 wherein the authorization related data set includes deviceinformation which includes fraud related information related to aplurality of devices that the user of the client device has used incommunication network transaction(s) in the past.
 6. The computerimplemented method of claim 1 further comprising: authenticating thepolicy enforcement point system to the cloud fraud service.
 7. Acomputer program product comprising: a machine readable data storagedevice; and machine readable data stored in the data storage device, themachine readable data including: first program instructions programmedto collect, in a fraud related data cache of a policy enforcement pointsystem through a communication network and from a plurality of cloudfraud services, machine readable fraud related data, second programinstructions programmed to intercept, by the policy enforcement pointsystem, a response being transmitted over a communications network froma cloud fraud service to a client device, with the response beingresponsive to a request generated by a browser script in a browser ofthe client device, third program instructions programmed to determine,by the policy enforcement point system, an authorization related dataset, based, at least in part, on the machine readable fraud relateddata, with the authorization related data set relating to a fraud riskof at least one of the following: the client device, or a user of theclient device, fourth program instructions programmed to modify, by thepolicy enforcement point system and to generate a modified response,session data included in the intercepted response to filter outsensitive data so that any sensitive data that is present in theintercepted response will not be present in the modified response, andfifth program instructions programmed to send, by the policy enforcementpoint system through the communication network, the modified response tothe client device.
 8. The computer program product of claim 7 whereinthe machine readable data further includes: sixth program instructionsprogrammed to send, by the policy enforcement point system to anapplication server involved in a communication session with the clientdevice, the authorization related data set.
 9. The computer programproduct of claim 7 wherein the machine readable data further includes:sixth program instructions programmed to propagate, by the policyenforcement point system, the authorization related data set to theplurality of cloud services.
 10. The computer program product of claim 7wherein the authorization related data set indicates fraud having beenconducted against the user or underway on the client device.
 11. Thecomputer program product of claim 7 wherein the authorization relateddata set includes device information which includes fraud relatedinformation related to a plurality of devices that the user of theclient device has used in communication network transaction(s) in thepast.
 12. The computer program product of claim 7 wherein the machinereadable data further comprises: sixth program instructions programmedto authenticate the policy enforcement point system to the cloud fraudservice.
 13. A computer system comprising: A set of processor(s) amachine readable data storage device operatively connected to the set ofprocessor(s) so that the set of processor(s) can execute programinstructions stored in the data storage device; and machine readabledata stored in the data storage device, the machine readable dataincluding: first program instructions programmed to collect, in a fraudrelated data cache of a policy enforcement point system through acommunication network and from a plurality of cloud fraud services,machine readable fraud related data, second program instructionsprogrammed to intercept, by the policy enforcement point system, aresponse being transmitted over a communications network from a cloudfraud service to a client device, with the response being responsive toa request generated by a browser script in a browser of the clientdevice, third program instructions programmed to determine, by thepolicy enforcement point system, an authorization related data set,based, at least in part, on the machine readable fraud related data,with the authorization related data set relating to a fraud risk of atleast one of the following: the client device, or a user of the clientdevice, fourth program instructions programmed to modify, by the policyenforcement point system and to generate a modified response, sessiondata included in the intercepted response to filter out sensitive dataso that any sensitive data that is present in the intercepted responsewill not be present in the modified response, and fifth programinstructions programmed to send, by the policy enforcement point systemthrough the communication network, the modified response to the clientdevice.
 14. The computer system of claim 13 wherein the machine readabledata further includes: sixth program instructions programmed to send, bythe policy enforcement point system to an application server involved ina communication session with the client device, the authorizationrelated data set.
 15. The computer system of claim 13 wherein themachine readable data further includes: sixth program instructionsprogrammed to propagate, by the policy enforcement point system, theauthorization related data set to the plurality of cloud services. 16.The computer system of claim 13 wherein the authorization related dataset indicates fraud having been conducted against the user or underwayon the client device.
 17. The computer system of claim 13 wherein theauthorization related data set includes device information whichincludes fraud related information related to a plurality of devicesthat the user of the client device has used in communication networktransaction(s) in the past.
 18. The computer system of claim 13 whereinthe machine readable data further comprises: sixth program instructionsprogrammed to authenticate the policy enforcement point system to thecloud fraud service.